16-4. LinkProof 設定のいろいろ

  (1) LinkProof 初期設定の辺り

   * ウィザ−ドについて

    [File]->[Wizards]->[First Time Wizard]          << 全部の設定を順番にやっていく。
                     ->[Redunduncy Wizard]                  << 
                     ->[Proximity Configuration Wizard]     << 以下のは部分的
                     ->[NAT Configuration Wizard]           << に設定を行なう。
                     ->[DNS Configuration Wizard]           <<


   * 設定のセ−ブとロ−ド

    < 設定をパソコンにセ−ブする >

    [File]->[Configuration File]->[Receive From Device] の画面で "File name [ kkk ]" 
    と入れた。パソコンの C:\Configware\Configware\Nms\Configuration\kkk にセ−ブされ
    た。バイナリのファイルである。

    < 設定をパソコンからロ−ドする >

    [File]->[Configuration File]->[Send To Device] の画面で "File name [ kkk ]" と入
    れてスタンドランプのアイコンをクリックすると、以下にあるファイルをリストする。フ
    ァイルを選ぶと [Reset] するか尋ねて来る。それで数分かかる。

        C:\Configware\Configware\Nms\Configuration\


   * コンフィグレ−ション・ファイル
                                                         
    [File]->[Configuration File]->Edit File]             LinkProofの他 WSP, FireProof, 
    ---------------------------------------------------  PeerDirector, CSD, CID。とそ
    |       Edit Configuration File                      れぞれ２〜３個のバ−ジョンが
    |-------------------------------------------------   プルダウン・メニュ−にある。
    | □  ■                                                           ｜
    |----------------------------------------------------------------  ｜
    |   File Name is relative to <Configware dir>\Nms\Configuration\   ｜
    |                                                                  ↓
    | Configuration file was downloaded from device [LinkProof version 3.61 and on ▼]
    |
    | -- Convert Configuration --------------------------------------
    | | Ber Formatted File    [ linkproof     ] [    Browse...    ] |
    | | ASCII  Formatted File [ linkproof.txt ] [    Browse...    ] |
    | | Progress Status       [    100%       ] [ Edit ASCII File ] |
    | ---------------------------------------------------------------
    | -- Direction --------------------------------------------------
    | | ◎ BER to ASCII      ○ ASCII to BER                        |
    | ---------------------------------------------------------------

    すでに設定したコンフィグレ−ションのファイルがある。BER フォ−マットの linkproof 
    というファイル名とする。C:\Configware\Configware\Nms\Configuration\linkproof。こ
    のファイルはバイナリで見ることはできない。これを目に見えるアスキ−フォ−マットに
    変換する。linkproof.txt という名前とする。これら記入してアイコンの ■ [Set] をク
    リックする。"Progress Status" のところで進行が青く出て来る。 [ Edit ASCII File ]
    をクリックすると、アスキ−フォ−マットになったファイルが出て編集できる。

        -----------------------------     これが表示されたアスキ−フォ−マットのコン
        |SET //1                          フィグレ−ション。 LinkProof#system config
        |{                                で出て来るのとは違っている。
        |ifAdminStatus.100001=up
        |ifLinkUpDownTrapEnable.100001=enabled
        |}
        |SET //2
        |   |


   * 日付と時刻の設定

    LinkProof#system time               << 時刻を表示する。
    Time is : 19 51 33

    LinkProof#system time set 15 22 00  << 時刻をセットする。    
    New time is : 15 22 00

    または [Device]->[Global Parameters] の "System Time [15:22:00]"で時刻を設定する。
    日付は "System Date (dd/mm/yyyy) [20/06/2004]" で設定できる。あるいは NTP で時刻
    を合わせることもできる。

    何か時計の進み方が早い。日付けもおかしくなる。時間の扱いは LinkProofはかなり重要
    なファクタ−でないのか。問い合わせたら装置のバグでファ−ムウェアのバ−ジョンアッ
    プに ROM も交換を要するので、代理店に送ってくれとのことだった。


   * 装置のリセット

    [Device]->[Reset Element] をクリックすると、 "Are you sure you want to reset the 
    device ?" と出て来る。[OK] をクリックすると数分間待ってくれと出る。 これでリセッ
    トしたわけだが、そのまま LinkProof にはアクセスできた。 特に設定が変わっているよ
    うな風もなかった。設定してあるポ−トのＩＰアドレスがデフォルトに戻ってしまうこと
    により、まるでアクセスできなくなるのでないかと思ったのだが。


   * Ｗｅｂベ−スで設定をセ−ブしてみる

    [File]->[Configuration]->[Receive from Device] をクリックすると

    Download Configuration File 画面が出てくる。File Format [ BER ▼] で {Set}をクリ
    ック。別な画面が出てくるので [保存] をクリック。ファイル保存先に"デスクトップ"が
    出てくる。適当なフォルダに移動する。ファイル名は ReceivefromDeviceXXXXX というよ
    うに毎回違った名前になる。[ BER ▼] の他に [ ASCII ▼]がある、こちらは画面に設定
    状態が表示されるのみでセ−ブはできない。


  (2) LinkProof の機能いろいろ

   * ＶＬＡＮの設定

    先ず [Device]->[VLAN Parameters] の IP VLAN Auto Config は "Enabled" にすること。

    [Device]->[VLAN]
    ---------------------------------------------------------------------   
    | Virtual LAN Table -- 192.168.2.2                                  |
    |-------------------------------------------------------------------|      
    |  [↑] [↓]  [→] [→]   [□]                                      |
    |-------------------------------------------------------------------| 
    |                                                                   |
    |     Interface Number   VLAN Type   Protocol   VLAN MAC Address    |
    |   --------------------------------------------------------------- |
    | 1 | 100000           | Regular   | other    |                   | |
    | 2 | 100001           | Regular   | ip       | XX:XX:XX:XX:XX:XX | |

    メニュ−のアイコンの左から [↑]Refresh, [↓]Set, [→]Insert, [→]Delete。 それに
    [□] Adding ports to VLAN である。ＶＬＡＮにポ−トを追加、削除するにはこのアイコ
    ンの Adding ports VLAN で行う。

    [Device]->[VLAN] の Interface Number 100001 は、ＩＰプロトコル用にあらかじめ作ら
    れているＶＬＡＮである。自分でＶＬＡＮを作ることができる。メニュ−の [Insert] を
    クリックすると、通し番号で 100002 から新しいＶＬＡＮを作る。ＶＬＡＮと言うのは幾
    つかのポ−トを同じセグメントにするということである。


   * アクセス制限

    ポ−ト８につないだ 192.168.2.6 のコンピュ−タでしか LinkProof にアクセスできない
    ようにする。しかもそのパソコンに入れた Configware ソフトからしかアクセスを許さな
    いようにした。ただし RS-232C のアクセスはこの設定においてもできる。 それで８番ポ
    −トにパソコンを接続して触っていると、この状態で外のホ−ムペ−ジも見れるような気
    がする。多分、実践配備した LinkProofでは外へはアクセスはできないようになっている
    はずである。あくまでも LinkProof のみのアクセスである。Dynamic NAT IP が関係する。
    
    [Security]->[Management Port]

       | Port Nunmber | SNMP     | Telnet   | Web      | SSL
    ---|--------------|----------|----------|----------|----------
     1 | F-1          | Disabled | Disabled | Disabled | Disabled 
     ：|  ：          |    〃    |    〃    |    〃    |    〃
     7 | F-7          | Disabled | Disabled | Disabled | Disabled 
     8 | F-8          | Enabled  | Disabled | Disabled | Disabled 


    [Security]->[Community Table]

       | Management Address | Community String | Community Access | Send Traps
    ---|--------------------|------------------|------------------|------------
     1 | 0.0.0.0            | public           | SUPPER           | Enabled

    このままでは、0.0.0.0 ということでどんなＩＰアドレスのホストからでもアクセスでき
    てしまう。このエントリの "Management Address" と "Community String" を [Edit] で
    編集しようとしてもできない。それで下記のようにいったんエントリ２を [Insert] で追
    加して、エントリ１を消去 [Delete] する。そして [Set] をやる。

    [Set] をやってエラ−が出たら、例えば "Management Address" を192.168.2.9 とか、今
    使用しているパソコンのＩＰアドレス以外を指定したような場合、いったん LinkProofの
    設定を終了する。そしてパソコンのＩＰアドレスを、 指定した 192.168.2.9 とかにして、
    エントリ１を [Delete] し、再度 [Set] をやると 0.0.0.0 のは消える。

       | Management Address | Community String | Community Access | Send Traps
    ---|--------------------|------------------|------------------|------------
     1 | 0.0.0.0            | public           | SUPPER           | Enabled
     2 | 192.168.2.6        | public           | SUPPER           | Enabled


   * Step 5. Load Balancing Parameters について 

    ------------------------------------
    | Dispatch Method は  [ Cyclic   ]   ＼  [LinkProof]->[Global Configuration]->
    | Client Aging Time   [ 60       ]   ／  [General] でも設定。
    | Open New ...        [ 無効     ]   ＼
    | Select New ...      [ 無効     ]    ｜
    | Session Tracking    [ Enabled  ]    ｜ [LinkProof]->[Global Configuration]->
    | Client Mode         [ Layer3   ]    ｜ [Client Table] でも設定。
    | Tos Type            [ Disabled ]   ／

    "Dispatch Method" は "Cyclic" がデフォルトになっている。 "Cyclic" は Round Robin
    により交互にポ−トにパケットを送出する。 他に "Least amount of traffic"(最小トラ
    フィック量)、"Fewest numbers of users"(最小ユ−ザ数)、"Fewest Bytes Number"(最小
    バイト数) それに Windows NT 何がしがある。よく使われるのは最小ユ−ザ数か最小バイ
    ト数である。"Dispatch Method" で "Cyclic" が有効な場合は NHR が両方とも"Regular"
    である場合である。どちらかが "Backup" だと、"Cyclic" 指定は無効になる。

    "Client Mode" は "Layer3" がデフォルトである。他 "Layer4" などある。レイヤ３だと
    ＩＰアドレス単位、つまりあるホストから外へのアクセスは同じポ−トを通って出ていこ
    うとする。同じポ−トを使う判断は、LinkProof 内にテ−ブルが作られ、あるＩＰアドレ
    スはどのポ−トを使っているかある時間登録される。この時間が "Client Aging Time"で
    ある。デフォルトは６０秒になっている。

    "Client Mode" が "Layer4" のレイヤ４だと、ＩＰアドレスとポ−トでの単位になる。同
    じホストから外へポ−ト８０番でアクセスするのと２５番でアクセスするのは別ものとみ
    なす。ロ−ドバランシングが働くと８０番の方はポ−ト１、２５番の方はポ−ト２を通す
    といったことができる。８０番の HTTP アクセスが高負荷だとすれば、２５番のメ−ルは
    空いている別なポ−トでアクセスするという。


   * Step 7. Connectivity Check について

    どちらかのリンクが途切れると、もう一方に代わるまでだいたい３０秒から１分ぐらいか
    かる。このパラメ−タが、"Polling Interval 10" と "Number of Retries 5"である。デ
    フォルトの値であるが、１０秒間隔で NHRであるル−タに生きているかチェックしにいく。 
    返事がないと、このチェックを５回繰り返す。つまり５０秒たったら、ル−タは死んでい
    ると判断し、生きている方のル−タだけになる。

    ------------------------------------------
    | Check Connectivity Status [ Enabled  ]
    | Check Connectivity Method [ SNMP     ]    << ここでは SNMP と PING だけある。
    | Polling Interval          [ 10       ]
    | Number of Retries         [ 5        ]
    | SNMP Object ID            [ 1.3.x.x. ]
    | SNMP Community            [ public   ]
    ------------------------------------------

    例えばポ−ト１を Regular、ポ−ト２を Backup で稼働させていたとする。内外のアクス
    スは、この間ポ−ト１経由を通っている。分かりやすく内側のネットワ−クにあるパソコ
    ンから外側にあるＷＷＷにアクセスしてたとしよう。手元のテスト環境では、同じサイト
    asahi.com にアクセスした。ここでポ−ト１側の NHR の電源を切ると、 １分程度通信が
    できなくなる。その後ポ−ト２経由でアクセスできるようになる。さらにポ−ト１側 NHR 
    の電源をオンにしたらどうなるか。電源をオンにしたところで、１分程してポ−ト１が復
    旧したと LinkProof は認識する。しかし、現在ポ−ト２を経由しているので、 そのまま
    ポ−ト２を通ろうとする。これは現在アクセスしているのが "Client Table" に登録され
    るためである。多分その登録された存在時間 "Client Aging Time"、デフォルトは６０秒、
    を過ぎると登録から抹消される。それから後のアクセスはポ−ト１を経由するようになる。
    "Client Aging Time" の間にアクセスがあると、その時点からまた６０秒伸びるというこ
    とになり、ずっとポ−ト２を経由するということになる。


   * Step 18. Dynamic Proximity Configuration について
                                                            
    -------------------------------------------------
    | Proximity Mode         [ Full Proximity Both ]
    | Proximity Aging Period [ 2880 ]
    | Check Retries          [ 2    ]
    | Check Interval         [ 5    ]
    | Hops Weight            [ 1    ]   << actual router hops。
    | Latency Weight         [ 1    ]   << in round-trip。
    | Load Weight            [ 1    ]   << traffic on a given NHR。
                    
    "Proximity Mode" は Inbound, Outbound, Both, No Proximity, Static Proximity があ
    る。Inbound は外から内へ、Outbound は内から外へのパケットである。Both はその両方
    である。Proximity は近接性、つまりどちらのポ−ト経由が近いのか、速く到達できるの
    かといったことである。それを値として、動的に計算し判断しましょうというのが、この
    Dynamic Proximity である。そうでなくどちらを通すかは決めてしまいましょうというの
    が、Static Proximity である。 Dynamic Proximity は Hops(ホップ数)、Latency(遅延)、
    Load(NHR のル−タ負荷) の値によって計算される。ここでの設定は [LinkProof]->[Load 
    Balancing Weights] で変更できる、ここでのメニュ−には "Cost Weight" パラメ−タも
    加わっている。"Cost Weight" は複数回線での全体料金を最小にしようという働きである。


   * Step 20. Static Proximity について

    Dynamic Proximity でなく Static Proximity でパケットを通すポ−トを決める場合であ
    る。Proximity、近接性を手動設定する。外部の特定のホストにアクセスするのに、 あら
    かじめどのル−タを通って行かせるのか指定する。上記では cisco と EWS の２つのル−
    タがある。この設定では３つのル−タまで指定できる。 指定できるＩＰアドレスは NHR1, 
    NHR2, NHR3 のところでドロップ・ダウンで選ぶようになっている。 つまり外のあるサ−
    バに内からアクセスするのに、こっちの経路の方が速いと思えば、そのように設定できる
    わけである。テストその１、その２で言えば、 cisco と EWS の２つの回線が同じ速度と
    して、cisco 側のプロバイダのホ−ムペ−ジに頻繁アクセスするなら、NHR1 は cisco の
    ＩＰアドレス、NHR2 には EWS のＩＰアドレスを指定する。

    動作をテストその１、その２の環境で確認した。NHR の EWS を "Regular" に、cisco を
    "Backup" にして、以下のように設定した。わざと "Backup"回線の方を通るかテストした
    のである。NHR1,2,3 は 192.168.2.1 か192.168.3.1 か空をドロップ・ダウンで選ぶ。こ
    れで内部ネットにある PC から 192.168.1.3 に ping する。192.168.1.3 の SRV ホスト
    で tcpdump でどこからパケットが来ているか、 あるいは "Client Table" でも知ること
    ができる。この設定は特定のパケットを、どこを通すかということで、Dynamic NAT など
    他の設定より優先される。しかしそもそも NHR1 ル−タがダウンした場合は、この設定は
    無視される。以下 From Address は 0.0.0.0 の任意ＩＰアドレスとしたが、 例えばテス
    トその２では外に出て行く代表ＩＰアドレスとして、192.168.2.6 としても一緒である。

    [LinkProof]->[Proximity]->[Static Proximity]

       | From Address | To Address  | NHR1        | NHR2        | NHR3
    ---|--------------|-------------|-------------|-------------|------------
     1 | 0.0.0.0      | 192.168.1.3 | 192.168.2.1 | 192.168.2.1 | 


   * Step 10. Basic NAT Table について

       | From Local   | To Local     |Port  | Router | From NAT | To NAT  | Basic
       |Server Address|Server Address|Number| Address| Address  | Address | NAT Mode
    ---|--------------|--------------|------|--------|----------|---------|---------
       |              |              |      |        |          |         |
     
    これは Static NAT の設定によく似ている。英文の説明を直訳すると、Basic NAT はロ−
    カルのＩＰアドレスの範囲と宛先のアプリケ−ションに基づき、時々のユ−ザのため１対
    １のマッピング変換をする。Basic NAT はソ−ス・ポ−トが変換されない任意のアプリケ
    −ションに有効である。それゆえクライアントのＩＰアドレスが、Dynamic NAT を使って
    変換されるようなのには用いることはできない。？、意味がよく分からないが。


   * [LinkProof]->[NHR Advanced Configuration]->[Aging By Application Port] について

    Step 5 での "Client Mode" が "Layer3" では働かない。ポ−トまで扱う "Layer4" でな
    いとだめである。例えば８０番ポ−トの HTTP アクセスは、LinkProof に登録しておく時
    間を指定したのにできる。多分 Step 5 での "Client Aging Time" が、今のところ "60"
    になっているが、それとは別に８０番ポ−トは "600"にするというようにできるのだろう。


  (3) LinkProof 一応知識として

   * Proxy ARP について − これで使えるようになるのでないか、未確認。

    [Router]->[ARP Table]
    -----------------------------------
    | Interface   [ F-1   ▼]       << F-1 から F-8 と 100001 が選択できる。
    | IP Address  [ 0.0.0.0 ]               << この２ヵ所を登録。別なセグメントにあ
    | Mac Address [ 00:00:00:00:00:00 ]     << るホストのＩＰとＭＡＣアドレスを記述。
    | Class       [ Static  ]       << Static しか出てない。
    ------------------------------------

    [Router]->[IP Router]->[Operating Parameters]

    - IP Router Parameters ----------------------
    | Inactive ARP Time Out [ 60000    ]
    | ARP Proxy             [ Disabled ]    << Enabled にする。
    | ICMP Error Messages   [ Enabled  ]


    < 参考：Proxy ARP の一般的な使用例 >

    ホストＡから別セグメントにあるホストＢにアクセスする。 Ａ# ping 192.168.2.1 とや
    る。192.168.2.1 のＭＡＣアドレスは何ですか？。するとホストＧがホストＢに代わって
    ＭＡＣアドレスは XX:XX:XX:XX:XX:XX ですよと応答をする。

        Ａ□                                              これはホストＢの
          ｜.2                      ホストＧでの設定      ↓ＭＡＣアドレス
        ------------ 192.168.1.0    # arp -s 192.168.2.1 XX:XX:XX:XX:XX:XX pub 
              ｜                    
              □ Ｇ   □ Ｂ         ホストＢでは ARP に応答しないようにしてある。
              ｜      ｜.1
        ------------------- 192.168.2.0


   * "Full Path Health Monitoring" の設定 

    [ インタ−ネットでの接続 ]                           □  [ 上記テスト環境 ]
                                                         ｜.3
    ／￣￣￣￣￣￣￣￣￣￣＼                    -------------------- 192.168.1.0
    ＼＿＿＿＿＿＿＿＿＿＿／                      ｜.11        ｜.12
       ｜1.9        ｜2.9                  Backup □ cisco     □ EWS2 (snmpd)
       □           □ プロバイダ側               ｜.1         ｜.2
       ：           ： にあるル−タ               ｜       ---------- 192.168.9.0
       ：           ：                 192.168.2.0｜         ｜.1
       □           □ NHR のル−タ               ｜ Regular □ EWS (snmpd)
       ｜1.1        ｜2.1                         ｜         ｜192.168.3.1  
      -------------------                      -------------------
      |    LinkProof    |                      |    LinkProof    |
      -------------------                      -------------------

    これまでの LinkProof の設定では、 実際のインタ−ネット接続のイメ−ジは左図のよう
    にになる。NHR のル−タの接続性のチェックは 1.1 と 2.1 のル−タを調べる。プロバイ
    ダ側にあるル−タはチェックしない。この状態で、プロバイダ側のル−タが停止したとし
    ても LinkProof はその異常を検出することはできない。 プロバイダ側のル−タもチェッ
    クさせようというのが、"Full Path Health Monitoring" の設定である。マニュアル１の
    "APPENDIX(a)" の設定例でも実施するように推奨している。 

    もし 1.1 のル−タを Regular、2.1 を Backup とした場合、 1.9 のル−タが故障とかし
    たらどうなるか。1.1 と 2.1 しかル−タの状態をチェックしない。 1.9 はチェックしな
    いため、Backup のル−タに切り替わらない。つまり通信不能になってしまう。 これまで
    プロバイダ側のル−タがおかしくて通信できなかったことは、実のところ一度もない。こ
    の設定はあまりシビアに考える必要はないかも知れない。

    ただし実際のインタ−ネット接続で、プロバイダのル−タのＩＰアドレスは明示的には教
    えてもらえないことが多いかも知れない。その場合は traceroute コマンドなどで調べて
    みよう。それに SNMP は先ず対応しないと思った方がいいだろう。 PING でさえ応答させ
    ないようル−タを設定している場合だって、実際あった。

    上記のテスト環境で実際に動作を確認してみた。テスト環境は実際は、このようにEWS を
    ２台用いている。ここでの確認テストには好都合だった。"Step 7. Connectivity Check"
    は "SNMP" であるとする。LinkProof からは EWS に SNMP パケットを送り、 生きている
    かチェックする。加えて EWS2 にも SNMP パケットを送り、同様チェックするのである。

    [LinkProof]->[Next Hop Router Table]
    ---------------------------------------------------------------------
    | [↑] [↓]  [〆] [→] [→]  [〇] [※] [□] [◇] 
    |--------------------------------------------------------------------
    |     NHR Address   NHR Name   Admin Status   Operational Status  
    |   -----------------------------------------------------------------
    |  1| 192.168.2.1 | cisco    | Enabled      | Active             |
    |  2| 192.168.3.1 | EWS      | Enabled      | Active             |
    |   -----------------------------------------------------------------
    ---------------------------------------------------------------------

    チェックのタ−ゲットとして EWS2 を加えるには、 上の表の "192.168.3.1" のところを
    クリックし、[※]の "Full path health monitor" をクリックする。すると以下のような
    追加画面が現われる。"192.168.9.2" を [Insert] で追加する。

       | Check Address | Operational Status 
    ---|---------------|--------------------
     1 | 192.168.3.1   | Active
     2 | 192.168.9.2   | Active             << アイコンの [Insert] で追加する。

       | Check Address | Operational Status 
    ---|---------------|--------------------
     1 | 192.168.9.2   | NotInService       << EWS2 の snmpd を止めたら。上のTableの
     2 | 192.168.3.1   | Active                "192.168.3.1"部も NotInService になる。
                                               EWS2 の電源を切っても同じようになる。

   * その後気付いたこと  `26/04 

    内部のホストからＷＡＮル−タに向けて ping それに traceroute をかけてみた。 

        ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣＼
        ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
                 | ADSL       | ADSL
              ---------    ---------
       Backup |Router1|    |Router2| Regular
              ---------    ---------
              (4)‖.126    .25|(5)   
    192.168.2.64 ‖           | 192.168.3.24 net
    net          ‖.125    .26| ↑.27 で外へ
              --------------------
              | (1)          (2) |
              |       (3)        | LinkProof Branch
              --------------------
                   .125‖    
                       ‖192.168.2.64 net
                    .65‖NAT
                    -------
                    |     |.1
                    |FIRE |----------------------- 192.168.10.0
                    -------        △内部ホスト
                     .1|(0)        ｜
            -----------*-------------------------- 192.168.20.0

    [ traceroute の経路が変？ ]

    右側ル−タへは # traceroute 192.168.3.25、 (0) -> (3) -> (5)。
    左側ル−タへは # traceroute 192.168.2.126、(0) -> (4)。

    右側ル−タへはいったん LinkProof の (1) のインタ−フェ−スを通って、(2) から (5)
    へ行くかと思った。パケットの経路は(0)->(3)->(5) ではなく、何故か見えないところが
    あって (0)->(3)->(1)->(2)->(5) じゃないのかと疑ったのである。確かに (2) は出て来
    ないので。いや、勘違いだった。LinkProof のインタ−フェ−スは、ここでの設定状態で
    は (3) と (1) は同じＩＰアドレスである。これでいいのだ。


    [ LinkProof の遅延が大きい？ ]

    Router2 に内部ホストから ping を打つと # ping 192.168.3.25、40〜50 ms の遅延があ
    る。これはこれで問題ないらしい。インタ−ネットへはこの遅延時間は加算されない。ど
    うなっているのか知らんが。内部ホストから Router1 への ping では数ms の遅延である。
    # ping 192.168.2.126。 上記の右ル−タへ行くのに LinkProof の左インタ−フェ−スを
    経由することにより、無用な遅延が発生しているのでないかと疑った。了解です。


  (4) LinkProof の要ＤＮＳについて

   * LinkProof のＤＮＳのキャッシュ時間について

    LinkProof の "DNS Responce TTL" はデフォルトの０秒ままでいいか？。そのままだと毎
    回、自社のＤＮＳサ−バと LinkProof に www.yyy.co.jp のＩＰアドレスは、何ですかと
    問い合わせに来られる。mail.yyy.co.jp も同じく。 多少アクセス元のＤＮＳサ−バで覚
    えてもらってもいいのでないか、たとえば５分程度はどうかと思う。２つのポ−トをレギ
    ュラ−とバックアップで運用するなら、問題がない限り、www.yyy.co.jp のＩＰアドレス
    は変わらない。問題が起きた時に、外部からのアクセスが５分間できなくなるということ
    である。

    -----------------------------------------
    | Responce Configuration
    |----------------------------------------
    | DNS Configuration
    |
    | DNS Responce TTL          [ 300      ]
    | Two Records IN DNS Reply  [ Disabled ]
    | URL to IP search Mode     [ Both     ]


   * ＤＮＳの制御ファイルの知識

    BIND 8 系列、ＤＮＳ制御ファイルの SOA の例
    -----------------------------------------------------
    |$ORIGIN example.jp.
    |$TTL   86400           << アクセスしにきたネ−ムサ−バには１日キャッシュされる。
    |@   IN SOA ns1.example.jp. hostmaster.example.jp. (
    |       2004121901  ; Serial  ＼
    |       86400       ; Refresh  ｜これらはスレ−ブからマスタ−への
    |       21600       ; Retry    ｜ゾ−ン転送の要求に関わる変数の値。
    |       2419200     ; Expire  ／
    |       1200        ; SOA TTL ( Negative Cache )、BIND 4 ではここが Minimum TTL。
    |       )

    Refresh -- BIND 8 以降には Notify 機構があるので、あまり気にしなくてもいいらしい。
               基本的には１次ネ−ムサ−バにアクセスして、 シリアル番号が増加していれ
               ば、２次ネ−ムサ−バ側にコピ−してくる時間間隔。

    Retry ---- Refresh 時間でゾ−ン転送できなかった場合、 成功するまで繰り返す時間間
               隔。限度は Expire の時間になる。

    Expire --- Refresh の時間より大きくすること。RFC1912 によれば通常は２〜４週間。
                                                                  
    SOA TTL -- 数１０分程度、RFC2308 のサンプルは２０分(1200)。存在しないような FQDN
               をアクセスした場合、それを記憶しておく時間。

    $TTL ----- １日から３日、RFC2308 のサンプルは１日(86400)。 BIND 4 代での Minimum
               TTL( SOA TTL ) がこの値である。

    かつて SOA TTL の値は１〜５日が適切とされてきた( RFC1912 )。BIND 8.2 以降、TTLの
    意味が変わり、新たに $TTL フィ−ルド設けられた。

    注意すべきは、Refresh 値を長い時間に設定してしまった場合、その間にレコ−ド情報を
    変更しても、それが２次ネ−ムサ−バに反映されるのは、Refresh 時間後になる。

    ※秒数と時間：3600 １時間、300 ５分、3600000 約６週間、360000 １００時間、約４日。


   * ＤＮＳ情報の変更作業

        現在のＤＮＳの状態

    /usr/local/etc/named.hosts   
    --------------------------------------------------------------
    |$TTL 86400                     << １日。
    |@ IN   SOA  ns.yyy.co.jp. satou.yyy.co.jp. (
    |            2004042402
    |            3600               << １時間。
    |            300 3600000 3600 ) ;

        LinkProof 設置、数日から１週間前ぐらいに変更する。named.rev なども。

    /usr/local/etc/named.hosts   
    --------------------------------------------------------------
    |$TTL 3600                      << TTL １時間に変更。
    |@ IN   SOA  ns.yyy.co.jp. satou.yyy.co.jp. (
    |            2004042403
    |            3600               << Refresh １時間。
    |            300 3600000 3600 ) ;

        当日。これでＤＮＳ２次サ−バに１時間後、ユ−ザは１時間後に有効になる。

    /usr/local/etc/named.hosts   
    --------------------------------------------------------------
    |$TTL 3600
    |@ IN   SOA  ns.yyy.co.jp. satou.yyy.co.jp. (
    |            2004042404
    |            3600
    |            300 3600000 3600 ) ;
    |
    | LinkProof 設置による設定内容


  (5) LinkProof は使っていけるか

   * 追加ラインはバックアップにするか  `26/06, `27/03

       ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣＼        DNS の１次も TCPにやってもらう。DNS
       ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／        は普段はいじることはないはず。
           ｜8.1：TCP        ：IIJ  ｜9.1
     DNS-1 □   ：           ：     □ IIJ の Mail Gateway Service(MGS)
      MX 9.1    ：1.0        ：2.0     メ−ル転送先 1.5
                ：           ：
    TCP側仮想 --：-----------：-- IIJ側仮想      TCPの回線ダウンした場合、メ−ル転送
      1.5◆   | □ LinkProof □ |   ◇2.5        先を 2.5 にするのは、MGS で設定変更
              -------------------   Mail-Store   してもらうしかない。 書面で一杯記入
                       |.9                       しての手続きでは間に合わない。 転送
           -------------------- 1.0              先の変更はできないと考えた方がいい。
                 |.2                             
       Cache  -------      192.168.2.0                  
       Server |hostG|---------- 
         □   -------       □ Mail-Store, POP3, Usermin
         ｜      |.2        ｜.1  
       ---------------------------------- 192.168.1.0              

    MGS でのメ−ル転送先は 1.5 でいい。2.5 にすることはできない。TCPの回線ダウンした
    場合、回線の復旧を待つのみ。ＷＷＷサ−バも外に出したとすると、DMZ にある場合のよ
    うに IIJ 側ＩＰアドレスに誘導するということはない。LinkProofは内から外へのアクセ
    スを負荷分散するのに使うのみとする。LinkProof どうもおかしい。メ−ルがある所に一
    箇所まともに送れない、懇意にしているＳＩ業者さんも大学で同じ問題が起こっていると
    いっていた。相手メ−ルサ−バは Postfix、自分とこのケ−スでは Post.Office、これが    
    関係しているの？。もう一つ問題がある、NetCache を経由すると何故か Windows Update
    や google にアクセスしにくい。ファ−ムウェアをアップすれば直るのか。一応購入した
    ところから新しいファ−ムウェアを送ってもらったが。メ−ルの対策、MGS を使えばメ−
    ルは相手には MGS からになるから、LinkProofに関係なくメ−ルは行くのでないか。いず
    れにせよ問題が起きないことが分かるまでは、LinkProof はかますことはできない。

    ADSL１本でも、特に外のホ−ムペ−ジへのアクセスが遅いという感じではない。そんな訳
    で LinkProof は取り外すことにした。2006/01に回線のトラブルが起きて、あたふたして。
    周囲の目が LinkProof に注がれ、ついに 2006/06 外した。両方とも ADSL なので、同じ
    局に収容される。局の装置が故障したら ADSL は両方共だめになる。バックアップという
    意味での設置は説得力にやや欠けるのである。TCP の回線がダメになった場合、局の装置
    がダメになった場合ではない。その時のバックアップということにする。いざという時は 
    LinkProof をかまして、hostG のマシンのデフォルトル−トのみを手動で変更すれば IIJ
    側回線を通るようになる。自社ホ−ムペ−ジとメ−ルのＭＸレコ−ドもＤＮＳで変更しな
    いといけないが、大した手間ではないだろう。でも誰でも出来るという代物でもない。こ
    うした装置をかます場合のつらいところである。

    注.LinkProof の名誉のために記述しておく。google などの問題を調べていて、どうも臭
    いのは LinkProof でも NetCache でもなく、そもそもMicrosoft の Windows ＯＳの問題
    らしいことが分かった。このことは "7-6. キャッシュサ−バを利用する, (5)キャッシュ
    サ−バの運用,今使っている NetCache はまだ使えるか `26/06" に書いた。 NetCache に
    限らずプロキシを通していると Windows パソコンでは、Windows Update がおかしい場合
    があるとのこと。今回は NetCache だけ通してもおかしくならなかった。はたまた下記の 
    "こういうことも可能です" での確認で、 LinkProof だけ通してもおかしくならなかった。
    両方通すと複合的におかしくなる。どうもそういうことらしいことが分かった。NetCache 
    を別なプロキシ・サ−バを購入して置き変えるか。LinkProof のファ−ムウェアをアップ
    させるだけで良くなれば、しめたものだが。`27/03


   * 追加ラインは特定アクセス用にするか  `27/03
    
        ネットワ−クカメラのパケットだけ、プロバイダ IIJ 側を通すようにする。

    上の追加ラインはバックアップにするかの話で、LinkProof は取り外して、後から引いた
    IIJ 側の回線は遊ばせている。ファ−ムウェアをアップして問題が解決されれば、IIJ 側
    回線はネットワ−クカメラのパケットと TCP側回線のバックアップとして使うようにした
    い。もしカメラＡを IIJ 回線の引き込み口近くに設置できるのであれば、Router2に直接
    カメラを付けるという手もある。この場合 LinkProof は取り外したままになるが。 まあ
    無理して LinkProof をかます必要はない。IIJ回線が離れているのであればカメラ専用に 
    ADSL 回線を引いてもいいだろう。ADSL は安いので、ちょっとしたことでどんどん引かれ
    る。取り引き先のＶＰＮ用とかよくある話だ、よい子でも１本引かれている。最近では食
    堂のオ−トレジで精算用でも管理用に業者が引いていた。下図は ybase7.txt "4-7. イン
    トラネット構築最終章, (2)２００５年からの基本ネットワ−ク" からのである。

        ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣＼
        ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
              TCP：   日本 IIJ：                            |海外
                 ：           ：カメラの                    |
                 ：           ：パケット         192.168.4.1|      ●カメラＢ
          Router1□    Router2□↑.27 で外へ             --------  ｜192.168.4.2
                 ‖.1      .25｜                         |ル−タ|------ 
    202.241.128.0‖           ｜192.168.50.24/29         --------  ■PC-B A-Gateクラ
          Regular‖.9      .26｜Backup                      |.1    ｜.2   イアント
              --------------------  50.29  50.28        --------------- 192.168.60.0
       Branch | (1)          (2) |   ◇    ◇ hostA"    ル−タは簡易ファイアウォ−ル
              |       (3)        |   仮想ＩＰ           と簡易ＤＭＺ機能もあるとする。
              --------------------   ◇    ◇ hostA'
                       ‖.9          .4    .3
          ======================================= 202.241.128.0
                  ‖               A-Gate       
                  ‖.2               □    □hostA      192.168.50.24/29は24〜31の８
      FireWall -------  192.168.2.0  ｜.3  ｜.1         個の範囲で、有効25〜30の６個。
               |hostG|---------------------------               
               -------                hostB□      ○カメラＡ   □PC-A
                  |.2                      ｜.1    ｜.9         ｜.8
          ----------------------------------------------------------- 192.168.1.0

    ネットワ−クカメラの設置テストの結果、海外側から日本側に設置したカメラの映像が遅
    かった。これは日本からは上がり方向のパケットになる。 テストの模様は ssl_vpn2.txt
    "16-5.A-Gate SSL-VPN と次候補, (2)A-Gate とネットワ−クカメラ"。テストした時は日
    中で、日本側から海外側へのカメラ映像はそんなに遅くなかった。それゆえ、カメラを使
    う時間帯を考えれば、そこそこ使えるのでないか。多分アメリカとだったら時差が１３時
    間とか１４時間とかあるので、カメラを使って顔を合わすとすれば、日本では朝８時前後
    がいいだろう。アメリカは夕方６時ぐらいである。日本側ではまだその時間帯は、社内ネ
    ットワ−クもインタ−ネットへのアクセスも少ない。アジアとやる時はちょっと困る。時
    差があまりないのである。例えば上海とは１時間しかない。


   * ネットワ−クカメラを設置する  `27/02

    [ PC-A からカメラＢの映像を見る場合 ]  日本から海外へのアクセス

    linkp3.txt "16-3. LinkProof 参考の設定例, (5)LinkProofの片肺飛行, プロバイダ１の
    DA128回線をADSLに変更する作業の確認" 参考のこと。TCP側がレギュラでIIJ 側がバック
    アップ。先ず全ての通信を TCP 側の Router1 経由とする。そして特定のＩＰアドレスだ
    け IIJ 側の Router2 を通るように LinkProof を設定する。 カメラの有る外部の特定の
    サイト 192.168.4.0 は Router2 側を通るように設定する。

    [LinkProof]->[NHR Advanced Configuration]->[Grouping]->[Destination Grouping]
    --------------------------------------------------
    | Destination Grouping Table Insert              |
    |------------------------------------------------|
    | Destination IP Address     [ 192.168.4.0     ] | このネットワ−クのホスト全て。
    | Destination Subnet Mask    [ 255.255.255.0   ] |
    | Next Hop Router Ip Address [ 192.168.50.25 ▽] |
    | Operational Mode           [ regular       ▽] |
    --------------------------------------------------


    [ PC-B からカメラＡの映像を見る場合 ]  海外から日本へのアクセス

    外部からカメラＡを直接見ることはできない。SSL-VPN 装置の A-Gate を経由してでない
    とだめである。カメラＡは A-Gate の制御下にある。ということはカメラＡを外からアク
    セスするのに、単純には IIJ側ラインを通すことはできない。パソコン PC-B でのA-Gate 
    へのアクセスを、IIJ 側を通すようにしなければならない。そのためには仮想ＩＰの仮想
    ＩＰをとる。A-Gateの 実ＩＰアドレス 192.168.2.3 は、 FireWall-1 で 202.241.128.4 
    に仮想ＩＰアドレスに既に設定されている。それを LinkProof で更に 192.168.50.29 へ
    と仮想ＩＰアドレスにするのである。この設定は hostAで既に行なわれていることである。

    ＤＮＳのレコ−ドの設定をいじる。いや、今のところＤＮＳには A-Gate のエントリは記
    述してない。A-Gate を利用する各パソコンの hosts ファイルに、ＩＰアドレスを記述し
    ている。もうすでに５０台以上のパソコンにそのような設定がされている。変更するのは
    ちょっとばかり大変である。とりあえず外からカメラＡを見たい人は、hosts の記述を自
    分で変えてねということにしよう。この際いっそ A-Gate のレコ−ドをＤＮＳに記載する
    のはどうか。パソコンは hostsとＤＮＳのどちらを先に見るのか、要確認。でもセキュリ
    ティ的にレコ−ド記載はあまり、よろしくないような気がやっぱりするのだが。

        C:\WINNT\system32\drivers\etc\hosts     Windows 2000 の場合での記述。IE のバ
        ------------------------------------    −ジョンは 6.0.x 代。 ag60.nix.co.jj 
        |127.0.0.1      localhost               は先に定義しておいたもの。消していい。
        |192.168.50.29  iijag.nix.co.jj         iijag.nix.co.jj が今回定義したもので、
        |202.241.128.4  ag60.nix.co.jj          こちらでアクセスすればいい。


   * こういうことも可能です  `27/03

     ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣＼
     ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
           TCP： ｜                                              IIJ： ｜2.1       
              ： □TCP DNS                                          ： □IIJ DNS
              ：                                                    ：          
       Router1■                                             Router2■↑.27 で外へ
              ｜.1                                                  ｜.25            
              ｜          仮想ＩＰ                  192.168.50.24/29｜
              ｜          ◇    ◆                                  ｜.26                
              ｜          ｜.4  ｜.3                   ----------------- LinkProof
          --------------------------- 202.241.128.0    | (2)       (1) | Branchはこ
                  |      A-Gate                        |      (3)      | れまでの設
                  |.2     □    ■hostA                ----------------- 定のまま
      FireWall -------    ｜.3  ｜.1                         .9｜
               |hostG|--------------- 192.168.2.0              ｜202.241.128.0
               -------          □hostB                      PC△.2
                  |.2           ｜.1                    DNS は 2.1 にすること
          --------------------------- 192.168.1.0       Gateway 202.241.128.9

    わざわざこういう構成もテストしてみた。これで何がしたいか、できるか。内部ネットワ
    −クのパソコンで NetCache を経由して LinkProof も通ると、google やWindows Update 
    の挙動がおかしいという問題があった。そこで LinkProof だけ通る場合は、 一体どうな
    るのか調べてみたかった。そもそも NetCache が問題なのか LinkProofの問題だったのか、
    はっきりさせたいという訳である。googleでは次の画面を出すのに出て来ないことがしば
    しばだった。２、３回やると出て来るという変な話。結果 google はおかしくなかった。

    Windows Update も問題なかった。 Windows 2000 で [コントロ−ルパネル]->[自動更新]
    どこもチェックは入れてないのだが。画面の "更新は Windows Update Web サイトからイ
    ンスト−ルできます"、ここをクリックすると１分ぐらい何やらやっていた。 数十個更新
    プログラムというのが出てきた。選択してインスト−ルするしないはこの次である。以前
    は、何やらやったままそれべくそうろうになってしまったのである。やはり NetCache が
    おかしいのだ。とりあえず LinkProof のファ−ムウェアはアップしておくことにする。

    ※テストはやることやったら直ちにパソコンＰＣは外すこと。ＰＣは無防備な状態で置か
      れることになる。一人でインタ−ネットの回線を使うわけだからスカスカ速いけど。